A provider of data communications services typically provides a customer access to a large data communication network. This access is provided at “edge equipment” that connects a customer network to the large data communication network. As such, service providers have a broad range of customers with a broad range of needs, the service providers prefer to charge for their services in a manner consistent with which the services are being used. Such an arrangement also benefits the customer. To this end, a Service Level Agreement (SLA) is typically negotiated between customer and service provider. An SLA is a contract between the customer and service provider specifying agreed-to service level commitments. A Service Level Specification is a technical specification of the service being offered by the service provider to the customer.
To provide predetermined levels of service to a given customer, a service provider may consider monitoring and controlling the traffic from the given customer. Such monitoring and controlling is often referred to as “traffic management”.
Traditionally, Ethernet networks have had no traffic management capabilities. The Ethernet standard, known as IEEE 802.3, specifies the use of a PAUSE frame that allows a client to request a pause in transmission from a terminal attached to a given port. However, the PAUSE frame may only be employed on per port basis and may only be employed with respect to directly attached devices, which are not necessarily the originators of the traffic requiring management.
Recently, the Institute of Electrical and Electronics Engineers (IEEE) introduced a user priority indication capability that enables the definition of up to eight service classes, also known as Classes of Service (CoS). A set of Ethernet frames that have the same user priority indication may receive the same level of performance within the service provider's network, where level of performance is usually measured in terms of frame loss ratio, frame delay and frame delay variation.
A standard known as IEEE 802.1Q defines an architecture for a general purpose Virtual Local Area Network (VLAN) that may be implemented within a customer network and describes a four-byte extension to Ethernet service frame headers known as an IEEE 802.1Q tag. This tag includes a number of fields, including a 12-bit VLAN-ID field and a three-bit “user priority” field used to signal compliant devices. These three bits (normally referred to as the “p-bits”) provide for eight possible values, which match those used in the known IEEE 802.1p user priority field. The p-bits and VLAN-ID may be used in an IEEE 802.1Q tag to provide an identity of a CoS and, therefore, may be said to represent a VLAN CoS ID.
To allow the deployment of Ethernet to carrier (e.g., service provider) networks, the Metro Ethernet Forum (MEF) has recently been active in specifying traffic management capabilities for a metro Ethernet network (MEN). See MEF Technical Specification “Ethernet Service Model, Phase 1” available from www.metroethernetforum.org and hereby incorporated herein by reference. The work includes specifying Ethernet traffic parameters and traffic conditioning (policing) algorithms and actions. The MEF traffic parameters include: committed information rate (CIR), excess information rate (EIR), committed burst size (CBS), excess burst size (EBS). The traffic conditioning algorithms and actions relate to how Ethernet service frames are handled when they are found to comply with the traffic measurement parameters and when they are found not to comply with the traffic measurement parameters.
A single Ethernet VLAN has a capability to support the transmission of Ethernet service frames requiring different classes of service (up to eight). This capability differentiates Ethernet VLANs from connections defined by other technologies such as Frame Relay (FR) or Asynchronous Transfer Mode (ATM).
The MEF has defined basic traffic management at the User-Network Interface (UNI). The UNI may be defined as the physical demarcation point between the responsibility of a service provider and the responsibility of a customer. The service provider may provide one or more connections, each known as an Ethernet Virtual Connection (EVC), through the MEN. An EVC may be considered an instance of an association of two or more UNIs. Notably, it is known that a given UNI can support more than one EVC through the use of a Service Multiplexing capability.
As specified in “Ethernet Service Model, Phase 1” an Ethernet service frame is defined as any Ethernet frame that conforms to an IEEE 802.3 approved standard and is transmitted across a UNI.
The MEF provides a definition of traffic management over a point-to-point EVC. As part of that definition, first provider edge equipment (PE) in a MEN may receive an Ethernet service frame from customer edge equipment (CE) in a customer network. The Ethernet service frame may be received over a first UNI. The provider and customer edge equipment may be switches, routers, switch/routers, or similar devices performing Ethernet transport/switching functions. The first PE then identifies the EVC to which the service frame belongs (i.e., the PE determines an Ethernet Virtual Connection Identifier, or “EVC-ID”) and sends the service frame to a second PE in the MEN, where the second PE is connected to a customer network via a second UNI. Notably, the second UNI is associated with the first UNI in the EVC. Identification of the EVC is defined as involving determining a VLAN identifier (VLAN-ID) from the IEEE 802.1 Q tag on the service frame, or from the Ethernet port identifier. A map may then be consulted to determine the identity of an EVC corresponding to the determined VLAN-ID. The sending of the Ethernet service frame to the PE connected to the UNI that is associated with the first UNI in the EVC may be accomplished in many ways, as the MEN may be implemented using a protocol of the choice of the service provider. Popular choices for MEN protocol include Ethernet, ATM, Multi-Protocol Label Switching (MPLS), FR, Internet Protocol (IP) and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH).
To further coordinate MEF traffic management, the MEF has defined a term “Class of Service Identifier”, or CoS-ID, for information derivable from an Ethernet service frame that allows the identification of a required Class of Service treatment of the Ethernet service frame. Continuing the example presented hereinbefore, the MEF has described the derivation of the CoS-ID from the EVC-ID alone or from the EVC-ID in combination with the p-bits from the user priority field of the IEEE 802.1Q tag.
The MEF recommends determining a CoS to associate with a received Ethernet service frame based, at least in part, on the VLAN CoS-ID. In particular, the VLAN CoS-ID may be used to determine CoS aspects such as a Bandwidth Profile and forwarding treatment. A Bandwidth Profile may used to specify the traffic parameters (e.g., CIR, CBS, EIR, EBS) that may be used for traffic policing and resource reservation.
An Ethernet LAN Service (E-LAN) is an Ethernet Service that is based upon a Multipoint-to-Multipoint EVC. From Section 6.1.2 of “Ethernet Service Model, Phase 1”: “In a Multipoint-to-Multipoint EVC, two or more UNIs must be associated with one another. An ingress Service Frame to the EVC at one of the UNIs must not result in an egress Service Frame at a UNI that is not in the EVC. The rules under which a frame is delivered to a UNI in the EVC are specific to the particular service definition. Typically, a single broadcast or multi-cast ingress Service Frame (as determined from the destination MAC address) at a given UNI would be replicated in the Metro Ethernet Network and a single copy would be delivered to each of the other UNIs in the EVC. This kind of delivery would also typically apply to a Service Frame for which the MEN has not yet learned an association of the destination MAC address with an EVC, UNI pair.”
While Ethernet Line (E-Line) Services, based upon point-to-point EVCs, may be used to create Private Line Services and Point-to-Point Virtual Private Networks (VPNs), E-LAN Services, based upon Multipoint-to-Multipoint EVCs, may be used to create Multipoint VPNs. In particular, Ethernet LAN Services may provide: intra-company connectivity; full transparency of control protocol service frames; and broadcast and multicast of individual service frames. New VLANs may be added without complex coordination between the customer network and the service provider network and may require only one connection to have multi-site connectivity.
The MEF E-LAN model is similar to a Virtual Private LAN Service (VPLS) in most aspects. According to Kompella, K., et al., “Virtual Private LAN Service” Internet Engineering Task Force (IETF) Internet Draft, May 2004, which may be found as draft-ietf-I2vpn-vpls-bgp-02.txt at www.ietf.org, a VPLS, also known as Transparent LAN Service, and Virtual Private Switched Network service, is a useful Service Provider offering. The service offered is a Layer 2 (of the well-known seven Open System Interconnect layers) VPN; however, in the case of VPLS, the customers in the VPN are connected by a multi-point network, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature. The document describes the functions needed to offer VPLS, and goes on to describe a mechanism for signaling a VPLS, as well as a mechanism for transport of VPLS frames over tunnels across a packet switched network. The signaling mechanism uses the known Border Gateway Protocol as the control plane protocol.
In essence, a VPLS glues several individual LANs across a packet-switched network to appear and function as a single LAN (see Andersson, L., and Rosen, E., “Framework for Layer 2 Virtual Private Networks (L2VPNs)”, IETF Internet Draft, June 2004, which may be found as draft-ietf-I2vpn-I2-framework-05.txt at www.ietf.org).
Alternative approaches include: those approaches which allow one to build a Layer 2 VPN with Ethernet as the interconnect; and those approaches which allow one to set up an Ethernet connection across a packet-switched network (see Martini, L., et al, “Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks”, IETF Internet Draft, July 2004, which may be found as draft-ietf-pwe3-ethernet-encap-07.txt at www.ietf.org). Both of these approaches, however, offer point-to-point Ethernet services. What distinguishes VPLS from the above two is that a VPLS offers a multi-point service. A mechanism for setting up Pseudo Wires for VPLS using the Label Distribution Protocol (LDP) is defined in Kompella, V., et al, “Virtual Private LAN Services over MPLS”, IETF Internet Draft, April 2004, which may be found as draft-ietf-ppvpn-vpls-ldp-03.txt at www.ietf.org.
The IETF Internet Drafts describe UNI network functions and core (provider) network functions (unlike the MEF specifications, which focus on the UNI). Often, the VPLS core is specified as IP/MPLS network using Pseudo Wires. The VPLS model allows for different Attachment Circuit (AC) network technologies and access network technologies such as Ethernet, ATM and FR. The Attachment Circuit is terminated at the adjacent provider edge equipment.
In reviewing the MEF E-LAN and VPLS definitions, it may be considered that, although the disclosed basic traffic management techniques are useful, several enhancements may be implemented to improve the experience of both the customer and the provider.